fix(mcp): reject an unsupported flag instead of registering it as the server name - #164

The bug

parseMcp consumes the flags it knows (--name, -t/--transport, -e/--env, -H/--header) and pushes everything else onto positional. A flag it does not know therefore survives as a positional and becomes the server name, with its value promoted to the command.

The most likely way to hit this is copying the engine-native syntax the PRD itself documents (claude mcp add -s user …):

moshcode mcp add -s user https://mcp.sentry.dev/mcp

Because the spec is spliced verbatim into each engine's native mcp add argv, the bad name is not just cosmetic — it lands in the argv as a flag:

claude   mcp add -s user -s -- user https://mcp.sentry.dev/mcp
gemini   mcp add -s user -s user https://mcp.sentry.dev/mcp
codex    mcp add -s -- user https://mcp.sentry.dev/mcp

mcpCommand runs that fan-out with no confirmation step, so the mistake propagates to every installed engine at once. There is no error and no warning; the run reports added.

mcp install --scope user https://… was also wrong, but differently: it fell through to a stdio command server needs an explicit --name, which points the user at the wrong problem entirely.

Reproduction

Real CLI, unpatched:

$ moshcode mcp add -s user https://mcp.sentry.dev/mcp
· registering -s → user across MCP engines…

Patched:

$ moshcode mcp add -s user https://mcp.sentry.dev/mcp
✗ unknown mcp flag "-s" — mcp takes --name, -t/--transport, -e/--env, and -H/--header; put a command's own flags after --
$ echo $?
1

The fix

13 lines in src/integrations.mjs. Once name and target are resolved, a token still starting with - was never consumed as a flag, so it is a typo or an engine-native flag moshcode does not take. Reject it and name the flags that are accepted.

Deliberately scoped:

• Only the name and command positions. A command's own flags are legitimate arguments, so mcp add tools npx -y srv and mcp add tools -- npx -y srv --port 3000 are untouched. Both have control tests.
• Nothing after --. src/mcp-catalog.mjs states that mcp add <name> -- <cmd> … "still takes anything", so the escape hatch is not second-guessed. The check skips the target entirely when it came from cmdParts.
• The check runs before the install/name branch so mcp install --scope … now reports the real cause instead of the misleading missing-name error.

Tests

New test/mcp-stray-flag.test.mjs, 16 tests. 8 cover the bug (short flag, long flag, misspelled supported flag, stray in the command position, the misleading install error, the error's contents, nothing reaching planMcpAdd, and a stray flag in front of a catalog name). 8 are controls asserting the opposite direction, so the fix cannot buy green by over-rejecting: flags after -- pass through, flags after the target stay arguments, every supported flag parses byte-identically, the catalog shortcut still resolves, a bare URL install still derives its name, the pre-existing missing-value guards still fire first, an unknown verb still reports an unknown verb, and a stdio install with no name still asks for --name.

Fail-before: 8 fail / 8 pass unpatched, 16/16 patched.

Full suite: 615 → 631 tests, 0 failures (pass 493 → 509, skipped 122 unchanged).

Note on the existing coverage

test/mcp.test.mjs:80 already exercises flag parsing, but its fixture is ["add", "tools", "--", "npx", "-y", "srv"] — the dash tokens sit after --, so they go to cmdParts and never reach the positional list where the defect lives. It passes unchanged, before and after.